Add analyzer section in project.assets.json file by martinrrm · Pull Request #7464 · NuGet/NuGet.Client

martinrrm · 2026-06-08T23:06:58Z

Bug

Progress: NuGet/Home#6279
SDK PR (draft): dotnet/sdk#54646

Description

Today project.assets.json does not record which analyzers a package contributes, and analyzers are applied regardless of PrivateAssets / ExcludeAssets / IncludeAssets. This PR implements the NuGet restore half of the "indicate analyzer assets in project.assets.json" feature (spec: NuGet/Home#14455). The SDK consumption half ships as a separate dotnet/sdk PR.

When a project opts in with <RestoreEnableAnalyzerAssets>true</RestoreEnableAnalyzerAssets>, restore now:

Emits an analyzers group under each package in the assets file, listing every analyzer assembly. Detection uses a new AnalyzerAssemblies pattern in ManagedCodeConventions (any .dll under analyzers/ at any depth, excluding satellite .resources.dll), so the layout isn't assumed to be fixed and analyzer discovery is shared with the rest of the content model.
Respects asset filtering. PrivateAssets, ExcludeAssets, and IncludeAssets filter analyzers like any other asset type. Analyzers excluded or transitively suppressed are written as a _._ placeholder (consistent with compile / runtime / native).
Attaches selection metadata to each entry: codeLanguage (cs/vb/fs/any) and, when present in the path, compilerApiVersion (roslynX.Y) — mirroring how content files carry codeLanguage — so the SDK selects applicable analyzers from metadata instead of parsing paths. The metadata is derived by scanning the path segments, since real packages place the language at a variable depth (for example analyzers/dotnet/roslynX.Y/cs/).

Gating. The feature is opt-in and only honored for projects targeting .NET 11 or greater. The .NET 11+ gate is applied at evaluation time in NuGet.targets (mirroring NuGetAuditMode), and the resulting value is honored per target framework: it flows through TargetFrameworkInformation.RestoreEnableAnalyzerAssets and is read in code by every restore entry point — CLI/DG-spec (MSBuildRestoreUtility), VS nomination (PackageSpecFactory), and static-graph restore (MSBuildStaticGraphRestore, which previously did not honor the property at all). A multi-targeted net10.0;net11.0 project therefore emits the analyzers group only for net11.0.

Telemetry. ProjectRestoreInformation reports AnalyzerAssets.Enabled (opt-in state) and AnalyzerAssets.Count (number of analyzer assets emitted, excluding _._ placeholders). Richer adoption/impact telemetry to inform the default-on rollout ships as a follow-up.

Public API & serialization. Adds TargetFrameworkInformation.RestoreEnableAnalyzerAssets, LockFileTargetLibrary.AnalyzerAssets, LockFileItem.CompilerApiVersionProperty, and the ManagedCodeConventions.ManagedCodePatterns.AnalyzerAssemblies pattern (with the AnalyzerAssembly property name). The Newtonsoft.Json and System.Text.Json paths round-trip the new analyzers group and its metadata; the per-framework restore property round-trips through PackageSpecWriter and the streaming reader. The lock-file cache key includes the per-framework flag so toggling it invalidates correctly.

PR Checklist

Meaningful title, helpful description and a linked NuGet/Home issue
Added tests
Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.

jebriede

Approving with a few suggestions.

jebriede · 2026-06-09T21:12:30Z

+        private static bool IsAnalyzerAssetPath(string path)
+        {
+            return path.StartsWith("analyzers/", StringComparison.Ordinal)
+                && path.EndsWith(".dll", StringComparison.OrdinalIgnoreCase)


The "analyzers/" prefix check is StringComparison.Ordinal (case-sensitive) while the .dll / .resources.dll checks are OrdinalIgnoreCase. If a package authored the folder as Analyzers/ this would skip it while the SDK's discovery (which we're mirroring) may still pick it up. Was case-sensitivity on the folder segment intentional? If not, consider OrdinalIgnoreCase for consistency with the extension checks.

Yes this was intentional, we are mirroring sdk analysis discovery from https://github.com/dotnet/sdk/blob/8283adc1579c8bc2afb4458c81cbda0c6eac4466/src/Common/NuGetUtils.NuGet.cs#L43-L53.

jebriede

Approving with an optimization suggestion.

jebriede · 2026-06-15T21:40:36Z


                telemetry.TelemetryEvent[UpdatedAssetsFile] = restoreResult._isAssetsFileDirty.Value;
                telemetry.TelemetryEvent[UpdatedMSBuildFiles] = restoreResult._dirtyMSBuildFiles.Value.Count > 0;
+                telemetry.TelemetryEvent[AnalyzerAssetsCount] = CountAnalyzerAssets(assetsFile);


CountAnalyzerAssets runs on every real restore and walks every target and every library to populate AnalyzerAssetsCount. When the feature is off (which is the default and the common case during rollout) the count is always 0, so we pay for the full nested walk to produce a constant. Is it worth short-circuiting when the opt-in is disabled? Something like:

Suggested change

telemetry.TelemetryEvent[AnalyzerAssetsCount] = CountAnalyzerAssets(assetsFile);

telemetry.TelemetryEvent[AnalyzerAssetsCount] =

(_request.Project.RestoreMetadata?.RestoreEnableAnalyzerAssets ?? false)

? CountAnalyzerAssets(assetsFile)

: 0;

The inner walk is cheap per library (frozen libraries return Array.Empty), so this is a minor optimization rather than a correctness concern.

I'm going to make some changes here (like you said it always return 0) for the Telemetry, but we always want this since it will help us decide when to make this new behavior as default.

Created a Telemetry spec for the feature https://github.com/NuGet/Client.Engineering/pull/3855

nkolev92

I think we're introducing a new implementation pattern in a couple of different places, but we already have an established one.

nkolev92 · 2026-06-16T00:29:53Z

      <Output TaskParameter="AbsolutePaths" PropertyName="RestoreOutputAbsolutePath" />
    </ConvertToAbsolutePath>

+    <ItemGroup Condition="'$(TargetFrameworks)' != ''">


Should we instead follow the logic for audit and pruning where the decision is made in code.

This implementation is only really a factor in standard CLI restore.
The other 3 restores share an implementation, this doesn't.

Done, and good catch!

nkolev92 · 2026-06-16T00:37:16Z

+            return lockFileItems;
+        }
+
+        private static bool IsAnalyzerAssetPath(string path)


I think we should be using ManagedCodeConventions here.

That's what knows how to find the patterns.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/ContentModel/ManagedCodeConventions.cs

Lines 529 to 540 in d66371a

NativeLibraries = new PatternSet(

conventions.Properties,

groupPatterns: new PatternDefinition[]

{

new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any?}", table: DotnetAnyTable),

new PatternDefinition("runtimes/{rid}/native/{any?}", table: null, defaults: DefaultTfmAny)

},

pathPatterns: new PatternDefinition[]

{

new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any}", table: DotnetAnyTable),

new PatternDefinition("runtimes/{rid}/native/{any}", table: null, defaults: DefaultTfmAny)

});

Added an AnalyzerAssemblies PatternSet to ManagedCodeConventions (a terminal {analyzerAssembly} token matching any .dll under analyzers/ at any depth, excluding .resources.dll satellites) and removed the hand-rolled IsAnalyzerAssetPath .

GetAnalyzerLockFileItems now consumes contentItems.FindItems(...). I kept the metadata derivation (codeLanguage / compilerApiVersion) as a segment scan rather than content-model patterns, because the pattern engine extracts properties at fixed positions and the language segment isn't at a fixed position in practice.

I sampled 12 popular analyzer packages (67 analyzer DLLs): 66% put the language after the compiler version (analyzers/dotnet/roslynX.Y/cs/…), with the language appearing at depth 1, 2, or 3 depending on the package. Expressing that in the content model would need an enumerated set of depth-specific patterns plus new parsers and would silently mis-tag anything deeper. The scan handles all positions uniformly. Happy to revisit if you'd prefer the pattern approach.

nkolev92 · 2026-06-16T00:37:58Z

        /// the group has items. Empty groups are left alone.
        /// </summary>
-        private static void ClearIfExists<T>(IList<T> group, Func<string, T> factory) where T : LockFileItem
+        private static void ClearIfExists<T>(IList<T> group, Func<string, T> factory, bool copyProperties = true) where T : LockFileItem


Can you explain what are the properties we're stopping from copying in the analyzers scenario?

The analyzer LockFileItems carry two metadata properties codeLanguage (cs / vb / fs / any) and, when present, compilerApiVersion ( roslynX.Y )

kartheekp-ms · 2026-06-16T05:22:29Z

+                int segmentLength = separator - segmentStart;
+                ReadOnlySpan<char> segment = path.AsSpan(segmentStart, segmentLength);
+
+                if (segment.Equals("cs".AsSpan(), StringComparison.OrdinalIgnoreCase))


The hard coded strings still cause allocations. Is there any way to avoid them?

The "cs" / "vb" / "fs" literals are interned by the compiler, so comparing against them — including "cs".AsSpan() over the literal doesn't allocate (added a comment noting this).

dotnet-policy-service · 2026-06-25T19:25:32Z

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 7 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.

…ventions detection Move the RestoreEnableAnalyzerAssets opt-in gating into code, per target framework. The value now flows through TargetFrameworkInformation and is read by every restore entry point, including static-graph restore which previously ignored the property entirely. Removes the project-level ProjectRestoreMetadata.RestoreEnableAnalyzerAssets and the NuGet.targets OR. Detect analyzers via a new AnalyzerAssemblies pattern in ManagedCodeConventions instead of the hand-rolled IsAnalyzerAssetPath, so detection is shared with the content model and matches the analyzers folder case-insensitively. Clarify the analyzer metadata derivation comment and trim an allocation in the compiler-version normalization. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Add five properties to the ProjectRestoreInformation event to size the impact of enabling RestoreEnableAnalyzerAssets by default before the rollout: - AnalyzerAssets.Excluded.Count - AnalyzerAssets.PackagesWithAnalyzers.Count - AnalyzerAssets.PackagesWithExcludedAnalyzers.Count - AnalyzerAssets.ExcludedByPrivateAssets.Count - AnalyzerAssets.ExcludedByExcludeAssets.Count The counts are derived from the resolved dependency graphs and the package file lists, so they are reported on every full restore regardless of whether the feature is currently enabled. This lets us measure how many packages and analyzer assemblies would stop being applied once PrivateAssets/ExcludeAssets are honored. AnalyzerAssets.Count is redefined as the number of analyzer assemblies that would apply (computed the same way), replacing the previous count of analyzer assets written to the assets file. Analyzer detection mirrors ManagedCodeConventions.ManagedCodePatterns. AnalyzerAssemblies as a cheap string check, avoiding a content-item collection allocation per package on the restore path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

martinrrm requested a review from a team as a code owner June 8, 2026 23:06

martinrrm requested review from kartheekp-ms and zivkan June 8, 2026 23:06

jebriede previously approved these changes Jun 9, 2026

View reviewed changes

martinrrm mentioned this pull request Jun 9, 2026

[spec] Indicate analyzer assets and respect analyzer filtering in project.assets.json NuGet/Home#14455

Open

kartheekp-ms reviewed Jun 12, 2026

View reviewed changes

Comment thread src/NuGet.Core/NuGet.Commands/RestoreCommand/Utility/LockFileUtils.cs Outdated

kartheekp-ms reviewed Jun 12, 2026

View reviewed changes

Comment thread src/NuGet.Core/NuGet.ProjectModel/LockFile/LockFileFormat.cs

kartheekp-ms reviewed Jun 12, 2026

View reviewed changes

Comment thread test/NuGet.Core.Tests/NuGet.Commands.Test/RestoreCommandTests/RestoreCommandTests.cs

martinrrm dismissed jebriede’s stale review via 95dcd89 June 15, 2026 18:21

martinrrm requested review from jebriede and kartheekp-ms June 15, 2026 20:44

jebriede previously approved these changes Jun 15, 2026

View reviewed changes

nkolev92 reviewed Jun 16, 2026

View reviewed changes

kartheekp-ms reviewed Jun 16, 2026

View reviewed changes

dotnet-policy-service Bot added the Status:No recent activity PRs that have not had any recent activity and will be closed if the label is not removed label Jun 25, 2026

martinrrm removed the Status:No recent activity PRs that have not had any recent activity and will be closed if the label is not removed label Jun 25, 2026

martinrrm dismissed jebriede’s stale review via 6d6559e June 25, 2026 23:36

martinrrm and others added 3 commits June 25, 2026 16:48

Add analyzer section in project.assets.json

592aa22

PR comments

cfb837e

martinrrm force-pushed the dev-mruizmares-analyzer-assets branch from 6d6559e to 963cbee Compare June 26, 2026 00:05

martinrrm force-pushed the dev-mruizmares-analyzer-assets branch from 963cbee to b7099ed Compare June 26, 2026 00:42

martinrrm requested review from kartheekp-ms and nkolev92 June 26, 2026 00:42

	NativeLibraries = new PatternSet(
	conventions.Properties,
	groupPatterns: new PatternDefinition[]
	{
	new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any?}", table: DotnetAnyTable),
	new PatternDefinition("runtimes/{rid}/native/{any?}", table: null, defaults: DefaultTfmAny)
	},
	pathPatterns: new PatternDefinition[]
	{
	new PatternDefinition("runtimes/{rid}/nativeassets/{tfm}/{any}", table: DotnetAnyTable),
	new PatternDefinition("runtimes/{rid}/native/{any}", table: null, defaults: DefaultTfmAny)
	});

Uh oh!

Conversation

martinrrm commented Jun 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bug

Description

PR Checklist

Uh oh!

jebriede left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jebriede left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nkolev92 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kartheekp-ms Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dotnet-policy-service Bot commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

martinrrm commented Jun 8, 2026 •

edited

Loading

kartheekp-ms Jun 16, 2026 •

edited

Loading